[00:14.490 --> 00:22.190]  It's August 2018. A sysadmin logs in to the control panel of a wind turbine in southern
[00:22.190 --> 00:28.210]  France to update its firmware. More than 600 kilometers away,
[00:28.210 --> 00:35.230]  their PHP session token appears on my screen. Eight months later, an Egyptian oil tanker
[00:35.230 --> 00:40.350]  pulls into the port of Sfax, Tunisia, with a malfunctioning alternator on board.
[00:40.350 --> 00:44.430]  From my vantage point, more than 1500 kilometers away,
[00:44.430 --> 00:47.870]  I learn that this ship will be out of commission for at least a month,
[00:47.870 --> 00:53.570]  and I learn the name and passport number of the engineer who's flying away to fix it.
[00:54.410 --> 01:00.310]  Just this summer, 13,000 meters above the Atlantic Ocean, the accountant of a Polish
[01:00.310 --> 01:05.990]  real estate group put the finishing touches on their annual financial report. The Word document
[01:05.990 --> 01:11.390]  she prepared reached my computer at the same time it arrived at the inboxes of her colleagues
[01:11.390 --> 01:16.810]  at her parent company, one of Europe's largest private commercial real estate trusts.
[01:16.890 --> 01:21.090]  How does this sort of thing happen? How do I get this kind of information,
[01:21.090 --> 01:26.530]  and how do we protect it in the future? I'm James Pavore. I'm a PhD student at
[01:26.530 --> 01:32.350]  Oxford University, where I research satellite cybersecurity. And today, I want to talk about
[01:32.350 --> 01:38.930]  the results of more than two years of experiments looking at real world use of satellite broadband.
[01:39.050 --> 01:43.410]  I do this work with a bunch of talented people from both the UK and Switzerland,
[01:43.410 --> 01:48.750]  and I'm honored to get to share what we've found. This actually started as a fairly small kind of
[01:48.750 --> 01:54.630]  summer project. What we wanted to do is take a look at some research from the mid to late 2000s
[01:54.630 --> 01:59.950]  and see if we could replicate these findings. And what was cool about this research is that
[01:59.950 --> 02:05.570]  these people found that there were these satellite television feeds that were encapsulating internet
[02:05.570 --> 02:09.870]  traffic as well, and that if you had the right equipment and the right know-how, you could
[02:09.870 --> 02:15.750]  actually find sensitive, unencrypted internet traffic inside those feeds. Now, a lot has changed
[02:15.750 --> 02:20.670]  both about the way we use satellites and the way we use the internet since 2005, right? We have like
[02:20.670 --> 02:25.330]  smartphones and stuff now. And so we wanted to update this research and also to make it a little
[02:25.330 --> 02:30.810]  bit broader and more systematic, kind of look at large-scale use of these patterns. So what we
[02:30.810 --> 02:36.010]  ended up doing is conducting a series of domain-focused experiments, looking at real-world
[02:36.010 --> 02:42.550]  users at land, at sea, and in the sky for these satellite internet connections. In total, we
[02:42.550 --> 02:48.550]  analyzed signals from 18 satellites in geostationary orbit with a combined coverage area of about 100
[02:48.550 --> 02:53.470]  million square kilometers. To put that into perspective, that means we were able to receive
[02:53.470 --> 02:59.650]  signals from as far away as parts of the United States and the Caribbean, China, and India. A massive
[02:59.650 --> 03:06.170]  coverage area for an attacker. And in all 18 of these feeds, we identified deeply sensitive internet
[03:06.170 --> 03:11.070]  traffic, whether it was being transmitted using those protocols that had issues we've known about
[03:11.070 --> 03:17.590]  since 2005 or using newer protocols that have replaced it. And it wasn't just any data. It was
[03:17.590 --> 03:23.530]  some pretty interesting traffic. We saw sensitive information from nine members of the Fortune
[03:23.530 --> 03:29.850]  Global 500 that we're able to identify. Traffic belonging to passengers on six of the ten largest
[03:29.850 --> 03:36.650]  airlines in the world by passenger count. Traffic belonging to maritime companies who together make
[03:36.650 --> 03:43.210]  up 40% of the world's cargo shipping capacity by volume. And traffic belonging to government
[03:43.210 --> 03:48.890]  agencies ranging from the postal service of an Eastern European nation to an actual Air Force
[03:48.890 --> 03:55.030]  jet belonging to a North African country. We even saw traffic from regular people like you. People
[03:55.030 --> 04:01.190]  who might browse Wi-Fi in a coffee shop or update their Instagram while they're on a cruise. Now,
[04:01.190 --> 04:06.030]  before I delve into kind of the meat of this traffic, how we got at it, and what it has inside,
[04:06.030 --> 04:10.530]  I want to kind of be sure we're all starting at the same point and give you a bit of a crash course
[04:10.530 --> 04:14.830]  in satellite communications. So I'm going to run through a very simple scenario here
[04:14.830 --> 04:21.090]  to kind of explain what satellite communications look like in practice. So here's our satellite.
[04:21.090 --> 04:26.630]  It's in geostationary orbit, which means it's 30,000 kilometers above the Earth's surface.
[04:26.650 --> 04:30.870]  We have a customer in the Atlantic Ocean who wants to talk to this satellite.
[04:31.730 --> 04:37.230]  And to do this, they want to visit a website over the satellite feed that's hosted over here
[04:37.230 --> 04:43.750]  in Ireland. We'll say it's Google.com. And they have a device on their boat that's called a VSAT
[04:43.750 --> 04:48.410]  terminal, or a Very Small Aperture Terminal, which is what they'll use for this connection.
[04:48.490 --> 04:53.490]  And that device was sold to them by an internet service provider who runs a ground station here
[04:53.490 --> 04:59.450]  in Madrid. We'll also imagine an attacker who's quite far away from this conversation, down here
[04:59.450 --> 05:04.590]  in Accra, but still wants to intercept the communications. So how does this play out?
[05:04.590 --> 05:08.790]  Well, because our satellite's in geostationary orbit, it doesn't move around. So our customer
[05:08.790 --> 05:13.890]  just needs to point their satellite dish at the sky and say, get me Google.com, using whatever
[05:13.890 --> 05:19.070]  weird satellite protocol is used in this network. The satellite is more or less a dumb bent pipe.
[05:19.070 --> 05:24.210]  It doesn't really do any processing or networking. It just sends that signal right back down on a
[05:24.210 --> 05:28.870]  focused beam towards the ground station in Madrid. You'll notice this beam is very narrow,
[05:28.870 --> 05:33.190]  so it passes over our attacker at Accra's head. They can't intercept this communication.
[05:33.190 --> 05:38.390]  Once we get to Madrid, the satellite internet service provider will convert this weird satellite
[05:38.390 --> 05:42.870]  protocol into normal IP traffic and route it to Google, just like if you were visiting a webpage
[05:42.870 --> 05:48.190]  at home, terrestrially. It'll get the response over the terrestrial internet and then beam it
[05:48.190 --> 05:54.970]  back up into space. It's worth noting that when I say beam up into space, this isn't a fast process.
[05:54.970 --> 05:59.290]  The round-trip time for a conversation like this can be as long as 700 milliseconds, because the
[05:59.290 --> 06:03.870]  speed of light is only so fast, and geostationary orbit, which is the kind of satellite we're
[06:03.870 --> 06:09.630]  looking at, is very far away. Once we finally make it out there, though, there's one last step,
[06:09.630 --> 06:14.650]  which is to beam this signal back down to Earth. Only this time, we'll do it with a kind of critical
[06:14.650 --> 06:19.230]  difference, which is because satellites are expensive and we want to serve a lot of customers,
[06:19.230 --> 06:23.630]  we'll send it on a really broad forward link signal. You'll notice that the footprint of
[06:23.630 --> 06:27.790]  this signal reaches both our attacker in Ghana and our customer in the Atlantic Ocean,
[06:27.790 --> 06:32.570]  so those radio waves carrying that response from Google will hit our attacker's satellite dish at
[06:32.570 --> 06:38.370]  the same time as they hit the customer's. This is the crux of satellite eavesdropping. An attacker
[06:38.370 --> 06:44.630]  can reliably expect to intercept the signal from very far away on these forward links, but they
[06:44.630 --> 06:48.990]  can't always be guaranteed to see both sides of the conversation, which is somewhat unusual for
[06:48.990 --> 06:54.870]  an eavesdropper. Additionally, we can kind of think about the security properties in this context,
[06:54.870 --> 07:00.490]  because if we're imagining, say, a vulnerability in Wi-Fi or GSM, where the attacker has to be in
[07:00.490 --> 07:05.490]  your city or in your neighborhood to intercept your communications, here an attacker can be in
[07:05.590 --> 07:09.730]  a different country or on a different continent from their victim. So what does an attacker
[07:09.730 --> 07:15.030]  actually need to pull off this attack? Let's talk a little bit about our threat model.
[07:15.190 --> 07:20.770]  So in this case, if the attacker is a nation state, it's very simple. They simply need a
[07:20.770 --> 07:25.750]  bit of money. There are companies out there that sell specialized modems for intelligence
[07:25.750 --> 07:30.490]  collection purposes, like this one, and you hook them up to a multi-million dollar ground station,
[07:30.490 --> 07:35.090]  like this one, and you're off to the races just listening to whatever satellite signals you want.
[07:35.090 --> 07:39.870]  And it's a pretty reasonable assumption to say that national intelligence services are doing this.
[07:40.510 --> 07:46.330]  However, they don't really give this equipment to PhD students. So I had to find a different way to
[07:46.330 --> 07:51.510]  information, and that prior research that talked about using television signals is kind of what
[07:51.510 --> 07:57.690]  led our next step. So we tried to see how far we could get using simple home television equipment
[07:57.690 --> 08:03.430]  that's widely available. We picked up this nifty flat panel satellite dish, which cost around 90
[08:03.430 --> 08:08.150]  bucks, although honestly you could get something free off of Craigslist or Gumtree most of the
[08:08.150 --> 08:12.330]  time. You may even have a satellite dish kind of like rusting on your roof that you could use.
[08:12.470 --> 08:15.450]  And then we got a card to interpret these signals in our computer.
[08:15.450 --> 08:21.110]  Now we used a professional end card, which tends to run about $200 to $300. You could use a much
[08:21.110 --> 08:26.230]  cheaper card in like the $80 price range at the cost of maybe not being able to comprehend the
[08:26.230 --> 08:31.330]  more complex internet signals, but you'd still definitely find something. Once we have this
[08:31.330 --> 08:37.730]  equipment, the next test is to actually use it to connect to a satellite signal. And figuring out
[08:37.730 --> 08:41.630]  where the satellite is is easy. It's public information, and since they're in geostationary
[08:41.630 --> 08:46.490]  orbit, they're not moving anywhere. But actually connecting is a little bit trickier. So let me
[08:46.490 --> 08:51.870]  show you what that looks like in our lab environment. So what we're going to go ahead
[08:51.870 --> 08:57.570]  and do is use a tool called EBS Pro, which is designed to help people find satellite television
[08:57.570 --> 09:02.050]  feeds to listen to if they want to watch TV on their computer. And we're going to scan to hunt
[09:02.050 --> 09:07.270]  for internet signals instead. Now what we're going to do is point our dish at a satellite that we
[09:07.270 --> 09:12.050]  think has internet service, say because of a press release. And we're going to scan the KU band of
[09:12.050 --> 09:15.810]  the radio spectrum, because that's what our equipment is set up for. And what we're looking
[09:15.810 --> 09:20.430]  for is kind of signal against all of this background noise that's indicative of channels
[09:20.430 --> 09:26.050]  that might have information. In this case, the signal is pretty noisy, but we do see a few distinct
[09:26.050 --> 09:31.030]  humps in the spectrum graph that might contain actual traffic inside them. We'll go ahead and
[09:31.030 --> 09:35.170]  tell our card to connect to this one and interpret it as a digital video broadcasting for satellite
[09:35.170 --> 09:40.430]  feed. After a few seconds, we get a lock, meaning that we found a satellite and we're listening to
[09:40.430 --> 09:45.090]  signals from it. Now for the demo, I'm going to connect to this weaker signal here because I know
[09:45.090 --> 09:49.570]  it has interesting information. You'll see the signal to noise ratio is pretty abysmal, so we're
[09:49.570 --> 09:53.510]  not likely to get all of the packets in this network, but hopefully we'll find something.
[09:53.610 --> 09:58.070]  I'll go ahead and real quick just jot down some information about the frequency, the orientation,
[09:58.070 --> 10:01.890]  and the symbol rate, because we're going to have to switch tools. This tool doesn't get us all the
[10:01.890 --> 10:06.490]  way, it's designed for television feeds, and what we really want is raw data from that digital video
[10:06.490 --> 10:11.910]  broadcasting signal. So to do that, I'll use a tool that's provided with our device, that PCIe card
[10:11.910 --> 10:16.310]  in the drivers. We'll lock to that signal we discovered, and then we'll kick off a quick
[10:16.310 --> 10:21.530]  recording. The amount of traffic you get in a recording like this is hugely variable. You could
[10:21.530 --> 10:25.850]  get a terabyte in a week, you could get a megabyte in a week, it depends on your equipment and the
[10:25.850 --> 10:30.430]  signal you're listening to. In this case, I'm just going to record a couple hundred kilobytes, and
[10:30.430 --> 10:34.450]  we'll take a look at the file and see if we have any indicators that it has internet traffic instead
[10:34.450 --> 10:40.350]  of television traffic. There's no trick here to differentiating between the two types. All I'm
[10:40.350 --> 10:46.590]  going to do is just kind of grep through that binary file for the string HTTP, which we would
[10:46.590 --> 10:51.230]  expect to see in an internet recording, but we wouldn't expect to see in a television feed.
[10:51.450 --> 10:59.130]  And sure enough, we see here what looks like the output of a SOAP API. At this point, this is a
[10:59.130 --> 11:04.310]  clear text information from someone else's internet signal using freely available tools and
[11:04.310 --> 11:08.890]  commercial off-the-shelf equipment. And that's pretty bad, right? They could have sensitive
[11:08.890 --> 11:13.950]  information just in this API string. But as an attacker, what we really want is to see if we
[11:13.950 --> 11:18.330]  can pull off something even worse. We want to understand the semantics of this connection, kind
[11:18.330 --> 11:22.690]  of the nature of the communications. And to do that, we have to delve a bit into the protocols
[11:22.690 --> 11:28.190]  that are being used. So in our research, we've looked at two protocols, although there are others
[11:28.190 --> 11:34.690]  out there. The first is called MPEG-TS. Now, you might be saying, MPEG, isn't that a video streaming
[11:34.690 --> 11:40.470]  format? And you'd be correct. MPEG is widely used across the internet for sending videos.
[11:41.070 --> 11:45.730]  It's used for satellite television video feeds, for example. And over the years, people have kind
[11:45.730 --> 11:50.770]  of added all kinds of weird additions. They've added the ability to, like, pause live satellite
[11:50.770 --> 11:57.350]  television or update your set-top boxes firmware over these feeds. And these functionalities have
[11:57.350 --> 12:03.770]  been kind of hacked together to offer interactivity and internet services. And so, inside all of these
[12:03.770 --> 12:08.450]  layers of weird protocols, you have a fairly standard container format that there's a lot of
[12:08.450 --> 12:13.710]  great tooling for working with. And so, in fact, if you're, like, really lucky and you get a high
[12:13.710 --> 12:18.170]  quality signal-to-noise ratio, you may just be able to open that file we saved in the desktop
[12:18.170 --> 12:23.630]  directly in Wireshark and start seeing real packets. This is kind of where prior research
[12:23.630 --> 12:27.910]  focused, because it was a pretty straightforward process to line up all the tools correctly.
[12:28.050 --> 12:31.170]  And then you could spend most of your time looking at the contents of the traffic, which is the
[12:31.170 --> 12:36.750]  interesting bit. However, MPEG-TS is still a used standard for satellite internet, but it's getting
[12:36.750 --> 12:43.550]  replaced by newer protocols like GSE, or generic stream encapsulation. GSE makes a lot more sense.
[12:43.550 --> 12:48.550]  It essentially has an IP layer, which is embedded inside of this generic stream, which is broken up
[12:48.550 --> 12:52.670]  into fragments and then put directly into that digital video broadcasting feed. So, you have none
[12:52.670 --> 12:57.790]  of the weird MPEG characteristics that are intended for video streaming and aren't relevant to internet.
[12:58.270 --> 13:03.130]  We found that it was particularly popular among enterprise customers. So, people who had an entire
[13:03.130 --> 13:08.090]  satellite transponder for their network, think like maritime customers or aviation customers.
[13:08.110 --> 13:13.470]  But these customers also had much better equipment than we do. They would spend tens to hundreds of
[13:13.470 --> 13:19.550]  thousands of dollars on signal processing hardware, whereas we're using, like, 200 bucks of a PCIe card.
[13:19.550 --> 13:24.150]  So, when we were trying to receive these signals, we were often missing fragments of IP packets and
[13:24.150 --> 13:28.450]  had super corrupted feeds, which meant that existing tools weren't able to parse these
[13:28.450 --> 13:33.870]  signals for us. We didn't get much help in that regard. So, what we did instead is build our own
[13:33.870 --> 13:41.370]  tool called GSE Extract. And the goal of GSE Extract is to forensically reconstruct PCAP files
[13:41.370 --> 13:47.750]  from corrupted recordings of GSE feeds. And it does this by taking some shortcuts. If we were
[13:47.750 --> 13:51.850]  designing a satellite modem, we would have to consider all of the edge cases and how a network
[13:51.850 --> 13:57.150]  operates or how a packet gets sent. But for GSE Extract, we can say, generally, we would expect the
[13:57.150 --> 14:02.730]  start of an IP packet to appear here. Or we would expect this fragment to belong to this payload.
[14:02.910 --> 14:07.330]  And by making some of those assumptions, GSE Extract is able to help us figure out what to do
[14:07.330 --> 14:13.830]  with between 50 and 70% of the frames that are hitting our dish. This is significantly better
[14:13.830 --> 14:18.070]  than an existing tool, which would just throw an error message because the feed is so corrupted.
[14:19.150 --> 14:24.090]  Hopefully, by the time that you're watching this recording, GSE Extract will be available on my
[14:24.090 --> 14:28.610]  research group's GitHub. It may take a little bit longer because we're still kind of doing
[14:28.610 --> 14:34.090]  some responsible disclosure review process stuff. But it should eventually end up there. In the
[14:34.090 --> 14:38.610]  interim, if you want to delve into how it works a little bit deeper, it's described in pretty
[14:38.610 --> 14:43.270]  high detail in a related academic paper that we published a few months ago in the appendix of that
[14:43.270 --> 14:49.910]  paper. So this is kind of what you get at the end of the day by using GSE Extract. This is a JPEG
[14:49.910 --> 14:55.430]  file that we intercepted from an engineer aboard a maritime vessel who was dealing with a maintenance
[14:55.430 --> 14:59.690]  issue and sending pictures to his colleagues. You'll see that we're able to get like the start
[14:59.690 --> 15:03.430]  of the packet. We're able to kind of figure out, you know, this is a JPEG file. We knew what port
[15:03.430 --> 15:07.850]  it was going to. We kind of knew the nature of the communications. But at some point, we start
[15:07.850 --> 15:12.070]  losing fragments. And then in the case of like a compressed file like this, we weren't able to get
[15:12.070 --> 15:17.490]  everything. That said, the first chunk of an IP payload often has the most interesting bits. It
[15:17.490 --> 15:21.970]  may be the entire packet, or it may be the parts that you care about from like a session login or
[15:21.970 --> 15:27.210]  something. And so we think this is still useful to an attacker, even if it's not 100% recovery,
[15:27.210 --> 15:32.770]  and allows someone to get away with $200 or $300 of home television equipment and do harm that
[15:32.770 --> 15:36.690]  they would otherwise need tens of thousands of dollars to play with in these networks.
[15:38.090 --> 15:44.710]  All right, so at this point, we're in a good spot. We have a satellite dish that we can use to talk
[15:44.710 --> 15:49.870]  to signals. We know that if those signals are in a digital video broadcasting for satellite format,
[15:49.870 --> 15:54.770]  which is very common from geostationary orbit, we can parse that using that PCIe card on our
[15:54.770 --> 16:00.610]  computer. Depending on the contents of those streams, we can use existing tools like DVBSnoop
[16:00.610 --> 16:06.930]  or Wireshark, or tools we've written ourselves like GSExtract, to get meaningful PCAP data out
[16:06.930 --> 16:11.930]  of it and understand the internet traffic inside. The next step is really to understand the impact
[16:11.930 --> 16:17.090]  of what we found. How does this affect modern users of terrestrial satellite communications,
[16:17.090 --> 16:23.310]  maritime, and aviation communication links? So across all three of these domains, there are a
[16:23.310 --> 16:28.130]  couple of general things we found that are worth highlighting. The first is that none of the ISPs
[16:28.130 --> 16:33.530]  we looked at appear to employ encryption by default. That is to say that individual customers
[16:33.530 --> 16:38.690]  might choose to encrypt their traffic, but the satellite ISP was sending over the satellite feed
[16:38.690 --> 16:44.870]  traffic in essentially the same format that was coming into the modem. What this means is that as
[16:44.870 --> 16:50.070]  an attacker, we had an ISP-level vantage point on the traffic that was coming to a customer.
[16:50.070 --> 16:55.070]  We saw every website they visited, every bit torrent they downloaded, every connection they made
[16:55.070 --> 16:59.190]  would pass over that satellite link and we would get it. But when we looked at the enterprise
[16:59.190 --> 17:04.110]  customers, this got even more interesting because a lot of these enterprise networks operate basically
[17:04.110 --> 17:09.270]  as a LAN environment across the satellite feed. A good example is a cruise line we were looking at
[17:09.270 --> 17:14.350]  that had Windows machines on all of their ships. And the internal Windows LDAP traffic
[17:14.350 --> 17:18.590]  from that network, that Windows local area environment, was being broadcast across the
[17:18.590 --> 17:24.250]  satellite feed. Getting to see Windows-to-Windows corporate LAN communications as a wireless
[17:24.250 --> 17:28.970]  eavesdropper is really unusual and we thought it was a particularly interesting angle because it
[17:28.970 --> 17:35.270]  got us behind the firewall of a lot of these big corporations' networks. So the first environment
[17:35.270 --> 17:39.210]  I want to talk about, the first domain, is terrestrial customers. And these were really
[17:39.210 --> 17:43.170]  interesting to us because they're real people, they're kind of your home internet users, and
[17:43.170 --> 17:48.490]  they care about privacy. Now, I know what you might be saying. You might say, wait a second,
[17:48.490 --> 17:53.630]  my browser has this lock icon on it which says that my traffic is encrypted. What could an
[17:53.630 --> 17:59.850]  eavesdropper do to cause harm to me? And I would say to you, convenient made-up straw man, that
[17:59.850 --> 18:04.970]  there's actually a lot that an attacker can do to mess with your communications in this context.
[18:05.610 --> 18:11.190]  So even though we can't see exactly the content of your communications, we get to see your DNS
[18:11.190 --> 18:15.790]  queries, for example, which is essentially every website you're visiting, and we can use that to
[18:15.790 --> 18:21.130]  piece together your browsing history. Additionally, those TLS certificates that you think are
[18:21.130 --> 18:25.590]  protecting your traffic, or protecting the contents of that traffic, but they're fingerprinting the
[18:25.590 --> 18:30.270]  websites you're visiting, which allowed us to determine like which networks devices belong to
[18:30.270 --> 18:35.910]  or generally where users were going. Now, this is a mild privacy concern. You don't want an entire
[18:35.910 --> 18:41.050]  continent to hear your browsing history. But it gets worse when you slip up. One of the most
[18:41.050 --> 18:46.710]  illustrative examples of this comes from a lawyer whose emails we intercepted across this feed. So
[18:46.710 --> 18:51.110]  this lawyer in Spain was communicating with one of his clients about an upcoming court case. He
[18:51.110 --> 18:56.290]  happened to be a defense attorney. And we intercepted the emails that were going to his inbox,
[18:56.290 --> 19:02.630]  because he was using POP3 to download them over the satellite link. And so this is obviously
[19:02.630 --> 19:07.250]  bad news for that attorney's client, and for attorney-client privilege, and customer privacy
[19:07.250 --> 19:12.370]  in general, and all of that. But it gets a little bit worse if we think about it in the context of
[19:12.370 --> 19:17.250]  everything else we know about this lawyer. Because we also know what other websites he was visiting,
[19:17.250 --> 19:22.830]  and so we can say, hey, this lawyer goes to PayPal.com. We see that from his DNS queries.
[19:22.830 --> 19:26.590]  We have his email address, and we can read everything that goes to his inbox.
[19:26.590 --> 19:32.170]  We can go and hit the reset my password link on PayPal, and essentially hijack his accounts.
[19:32.250 --> 19:36.270]  This demonstrates how a man-in-the-middle attacker who's listening to your entire connection,
[19:36.270 --> 19:40.930]  who's essentially an internet service provider, can engage in attacks that are way more sophisticated
[19:40.930 --> 19:44.910]  than someone who's just eavesdropping in a single connection to an insecure service.
[19:46.750 --> 19:51.030]  So, the other thing we were curious about were kind of IoT systems, because these didn't really
[19:51.030 --> 19:54.990]  exist when people were looking at these feeds last time, especially in kind of the electricity
[19:54.990 --> 20:00.350]  and critical infrastructure domain. We found that a lot of operators seem to be using these
[20:00.350 --> 20:05.030]  networks under the assumption that they were secure against eavesdropping. A great example
[20:05.030 --> 20:11.770]  of this is a major electricity provider in Europe who had this HTTP basic authentication login that
[20:11.770 --> 20:17.050]  you see on the left to access the Cisco router inside their network's configuration page.
[20:17.290 --> 20:21.030]  And I've blocked out all of the sensitive information, but clearly this is a clear text
[20:21.030 --> 20:25.430]  admin username and credential that could probably change some settings on that router.
[20:25.630 --> 20:29.830]  And if you have a keen eye, you'll see that the host IP address for this router is publicly
[20:29.830 --> 20:34.310]  routable, meaning that anyone with an internet connection could use these credentials to log
[20:34.310 --> 20:39.370]  into the device. Very similarly, I kind of touched on this at the beginning, there are a lot of wind
[20:39.370 --> 20:43.190]  turbines that use satellite connections because they're in remote locations and they don't have
[20:43.190 --> 20:48.350]  terrestrial internet access. And what we found is that a lot of them have these control panels that
[20:48.350 --> 20:53.690]  were used to configure the devices that were being sent over the satellite feed. And these control
[20:53.690 --> 20:59.010]  panels are publicly routable over the open internet. So we could get these credentials that were being
[20:59.010 --> 21:03.270]  leaked in clear text over the satellite feed, whether that be a login cookie or username and
[21:03.270 --> 21:08.070]  password, and combine it with any internet connection to potentially start messing around
[21:08.070 --> 21:12.330]  with these power generation facilities. Now, obviously, we didn't engage in any attacks on
[21:12.330 --> 21:16.210]  an electrical grid system. So there could be another protection when you log in as some sort
[21:16.210 --> 21:20.510]  of second factor control. But I think it's intuitively concerning that this stuff is
[21:20.510 --> 21:27.350]  getting sent in clear text. So heading out to sea for a moment, I think one of the most interesting
[21:27.350 --> 21:32.330]  things for us about the maritime case was how unique every boat in the network is. So we had
[21:32.330 --> 21:36.430]  these terabytes and terabytes of traffic from all kinds of different companies and all kinds of
[21:36.430 --> 21:41.770]  different ships. And what we really wanted to do was figure out a way to tie an IP address in this
[21:41.770 --> 21:47.870]  massive PCAP file to a specific boat in the ocean to figure out what it was doing. So we picked 100
[21:47.870 --> 21:52.610]  random IP addresses from the thousands that we had, and we set ourselves a little challenge.
[21:52.610 --> 21:57.930]  We designed a fingerprint based off of DNS queries and TLS certificates and a couple of strings from
[21:57.930 --> 22:02.850]  the first few kilobytes of their traffic. And we used that to see if we could de-anonymize IP
[22:02.850 --> 22:08.810]  addresses and identify ships. This very basic kind of manual process was sufficient to de-anonymize
[22:08.810 --> 22:13.910]  10% of the vessels in that case study. So we de-anonymized 12 vessels. I've hidden their names
[22:13.910 --> 22:18.330]  here because I want to maintain the privacy of their owners, but you get a real sense for the
[22:18.330 --> 22:23.730]  breadth of the type of ships impacted by this research. So the smallest fleet that we listened
[22:23.730 --> 22:28.530]  to was this fishing fleet here, which had a single fishing vessel and was using some sort of software
[22:28.530 --> 22:33.510]  over the satellite feed to help it find fish. I'm not really sure how it works. On the flip side, we
[22:33.510 --> 22:37.610]  have this enormous container ship, one of the larger container ships in the world, belonging to
[22:37.610 --> 22:42.250]  one of the larger shipping companies in the world. And it's operating within the same kind of IP
[22:42.250 --> 22:48.230]  address space as that random fishing crew. Beyond being able to identify like which companies and
[22:48.230 --> 22:52.670]  organizations are affected, another cool thing we could do is kind of fingerprint operational
[22:52.670 --> 22:58.310]  technology aboard the vessel. A good example is this subsea repair ship down here, which is owned
[22:58.310 --> 23:03.390]  by a major petroleum company. And we were able to identify from the traffic inside those PCAP
[23:03.390 --> 23:07.830]  files that there was a device on board the ship running a vulnerable version of Windows Server
[23:07.830 --> 23:13.490]  2003 that had all kinds of CVEs that could be deployed against it. At this point, if we wanted
[23:13.490 --> 23:19.350]  to attack that ship, we could potentially deploy CVEs not just against that one, but against any
[23:19.350 --> 23:24.930]  ship in this petroleum company's fleet and potentially cause some serious harm.
[23:26.090 --> 23:30.850]  So another piece of operational technology we were curious about was something called
[23:30.850 --> 23:37.350]  electronic chart display and information systems, or ECTIS. And ECTIS are essentially GPS nav terminals
[23:37.350 --> 23:42.470]  for boats. They tell boats like where they can go safely or illegally. They have like various
[23:42.470 --> 23:47.230]  hazard updates for mariners. And there's been a lot of great research on securing them. There are
[23:47.230 --> 23:51.450]  actually formats out there to stop people from tampering with these charts using various
[23:51.450 --> 23:55.870]  cryptographic authenticity guarantees. Unfortunately, we saw that a lot of maritime
[23:55.870 --> 24:01.750]  operators were using older or proprietary versions of these formats that did not have protections
[24:01.750 --> 24:06.950]  against tampering attacks that we could see. Now, you might be saying, why does this matter, right?
[24:06.950 --> 24:10.790]  You can get free nautical charts and maybe save a couple hundred bucks if you want to go on a
[24:10.790 --> 24:15.670]  sailing expedition. But can you really mess with this data as someone who's just passively listening
[24:15.790 --> 24:21.130]  to a satellite connection? It turns out that you can, because a lot of these are updated insecurely.
[24:21.130 --> 24:26.850]  A great example is this ship, which had a publicly routable FTP server on board.
[24:27.010 --> 24:30.150]  And the way they would get their chart updates is someone on land in the back office
[24:30.150 --> 24:35.410]  would copy the latest chart files into a folder called chart delivery on an FTP server,
[24:35.410 --> 24:40.210]  and then it would get deployed to the ECTOS terminal. Now, because this FTP server is
[24:40.210 --> 24:44.170]  accessible over the internet, anyone with an internet connection can connect to it.
[24:44.170 --> 24:49.050]  And the password is getting sent in clear text over the satellite feed because they didn't use SFTP.
[24:49.050 --> 24:53.550]  And so it would be pretty trivial to send a false chart to this folder or even deploy
[24:53.550 --> 24:59.150]  targeted malware. Another common way that charts get update is via emails. And generally there's
[24:59.150 --> 25:05.710]  an email address like chartupdates underscore ship name at shipcompany.org, which will get
[25:05.710 --> 25:10.450]  updates every so often as attachments to the inbox. The captain will copy those files onto
[25:10.610 --> 25:15.190]  a flash drive, walk over to the ECTOS terminal, plug it in, and kind of update the information.
[25:15.910 --> 25:20.290]  That's not inherently insecure, but if you're like this captain and you use an insecure email
[25:20.290 --> 25:25.110]  protocol, then we get a pretty good template for a targeted social engineering operation
[25:25.110 --> 25:30.090]  that might persuade you to copy malicious charts or malware onto your own vessel's
[25:30.090 --> 25:36.170]  critical operational technology. Beyond this kind of operational technology, I think it's
[25:36.170 --> 25:41.790]  important to remember that there are real people aboard these ships who have real privacy concerns,
[25:41.790 --> 25:46.690]  like billionaires sailing around on their super yachts. Now I know getting up at DefCon and saying
[25:46.690 --> 25:51.690]  think of the billionaires is not a great starting point, but this was a really fun case study that I
[25:51.690 --> 25:56.170]  want to kind of delve into a little bit. So we were listening to this traffic from this Greek
[25:56.170 --> 26:01.330]  billionaire's mega yacht, and there were all kinds of interesting anecdotes that came up in the
[26:01.330 --> 26:06.130]  traffic that really painted a picture of what was going on. For example, one day the captain of this
[26:06.130 --> 26:12.010]  yacht forgot to log in to his Microsoft account, and so the credentials for that captain's account
[26:12.010 --> 26:16.630]  came across the satellite feed in clear text in the format of an account reset link.
[26:16.930 --> 26:20.650]  Now at this point, we could hijack the account of someone who has reason to communicate
[26:20.650 --> 26:25.090]  with a very high net worth individual and potentially engage in some super targeted
[26:25.090 --> 26:29.930]  social engineering attacks. Because the captain's email address included the name of the yacht,
[26:29.930 --> 26:34.310]  we could also very easily identify which billionaire was affected by this traffic.
[26:35.630 --> 26:40.070]  Additionally, once we had kind of de-anonymized the owner of this yacht, there were other things we
[26:40.070 --> 26:45.310]  could piece together. For example, the yacht used software to manage, like, lunch orders and stuff
[26:45.310 --> 26:49.470]  for the crew members and for guests, and so we could see who this billionaire was inviting on
[26:49.470 --> 26:53.850]  their yacht or where they were going or even what they were eating for lunch on a particular day,
[26:53.850 --> 26:57.910]  which is, like, not inherently sensitive, but if you're hiding who you're meeting or you don't want
[26:57.910 --> 27:01.910]  an entire continent to know about your social life, it could be a little bit concerning for
[27:01.910 --> 27:06.630]  these individuals. Beyond the billionaires, though, there are also regular people on
[27:06.630 --> 27:12.650]  vessels across the sea who have privacy concerns. Another privacy thing that we encountered was what
[27:12.650 --> 27:17.150]  looked like point-of-sale terminal traffic coming off of cruise ships from a major European cruise
[27:17.150 --> 27:21.990]  operator. And I don't know if there were credit card numbers in here, so I've censored the data
[27:21.990 --> 27:26.510]  very heavily. A lot of the numbers did pass the loan check, but it could have been coincidental.
[27:26.810 --> 27:30.810]  At the very least, anything that tells you how much someone paid for a soda, what their name was,
[27:30.810 --> 27:36.690]  is pretty deeply concerning that it's being broadcast across an entire continent in clear text.
[27:37.230 --> 27:40.850]  Another example of sensitive information from, like, real people on cruise ships
[27:41.370 --> 27:47.290]  or on vessels would be when ports have cargo vessels come in. They often require the crew to
[27:47.290 --> 27:52.250]  share some visa information. And this particular port authority thought that a great way to do that
[27:52.250 --> 27:57.230]  would be an insecure HTTP web service. And so as a result, we could see from the cargo vessels
[27:57.230 --> 28:01.950]  pulling into this port, all of the names and passport numbers and date of birth of the crew
[28:01.950 --> 28:06.670]  members aboard these ships. Obviously, this is deeply sensitive information that should have
[28:06.670 --> 28:12.570]  been encrypted. All right, let's head out to the skies. So the aviation use case is really
[28:12.570 --> 28:17.430]  interesting to me because it's the newest one. We were going to do this as our 2020 experiment.
[28:17.430 --> 28:21.470]  We're going to get all kinds of great data from airplanes this year and really get a feeling for
[28:21.470 --> 28:26.670]  how aviation intersects with satellite communication security. And we started out great. We had some
[28:26.670 --> 28:31.250]  great traffic from these in-flight entertainment systems in February. We're super excited for the
[28:31.250 --> 28:37.890]  year. And then everyone stopped flying. The number of people in airplanes sank dramatically because
[28:37.890 --> 28:42.090]  of the pandemic. And so the amount of traffic we were getting also tanked. I was originally
[28:42.090 --> 28:46.950]  pretty salty about this, but then I realized that there's actually a silver lining here.
[28:47.390 --> 28:52.210]  You see, back in February, the traffic we were seeing was a lot, but it was mostly garbage. It
[28:52.210 --> 28:56.030]  was people checking their Facebook on a flight, which isn't that interesting from a security
[28:56.030 --> 29:01.130]  researcher perspective. But in April, when the airplanes were flying empty, almost all of the
[29:01.130 --> 29:05.470]  traffic in these networks was somehow essential to either the operation of the airline or the
[29:05.470 --> 29:09.990]  operation of the airplane. There were no passengers to generate noise. And even as passenger counts
[29:09.990 --> 29:14.810]  increased, the passengers we saw tended to be like high-value business executives as opposed to just
[29:14.810 --> 29:19.470]  random tourists, which made the traffic a little bit more interesting from a privacy perspective.
[29:19.990 --> 29:24.990]  Now, because we had this unique opportunity, there was something I wanted to test, which was a claim
[29:24.990 --> 29:29.970]  that was made by a researcher whose work I really admire. So Ruben Santamarta does research in satellite
[29:29.970 --> 29:34.330]  modems. He's definitely presented at Black Hat and DEFCON and stuff, doing a lot of hardware
[29:34.330 --> 29:38.570]  reverse engineering. And he has this blog post where he looks at in-flight entertainment systems,
[29:38.570 --> 29:43.370]  including some of the systems that we were seeing traffic from. And he posited that he suspects the
[29:43.370 --> 29:47.670]  satellite terminal could be a bridge between the part of the airplane that keeps people entertained
[29:47.670 --> 29:52.010]  and happy and the part of the airplane that keeps it in the sky and going in the right direction.
[29:52.010 --> 29:56.370]  And we wanted to see if there was anything in these traffic captures that crossed that red
[29:56.370 --> 30:00.730]  line and kind of crossed those two separate information security domains, which shouldn't
[30:00.730 --> 30:06.010]  be happening. We would have missed this if we had all of that Facebook traffic. We actually
[30:06.010 --> 30:10.870]  had traffic from this device for several months, and we didn't realize it until coronavirus hit.
[30:10.870 --> 30:16.070]  But we found what I'm going to call the loneliest EFB. So an EFB is an electronic flight bag. It's
[30:16.070 --> 30:20.650]  essentially an information terminal like an ECTIS terminal, but for airplanes it includes
[30:20.650 --> 30:24.950]  navigational information and weather updates and all kinds of stuff that the pilot needs to manage
[30:24.950 --> 30:30.270]  the flight. And this specific Chinese airline had made a mistake in configuring their EFB
[30:30.790 --> 30:35.190]  such that it wasn't logging in correctly. Someone had like fat fingered a password or something.
[30:35.190 --> 30:38.930]  And so all of the requests it was sending were getting bounced off of this redirect page from
[30:38.930 --> 30:44.170]  the satellite modem and reaching us. And we could use that to not only fingerprint like how this API
[30:44.170 --> 30:48.350]  works and what sort of data is being sent from the airplane and where the airplane was at any time,
[30:48.350 --> 30:54.870]  but we could also identify other vessels that were using this same device. And even though
[30:54.870 --> 30:59.910]  it seems to be encrypted over the air in most cases, we're able to confirm that the network
[30:59.910 --> 31:04.290]  that's carrying this operational technology traffic is the same one as the person a few
[31:04.290 --> 31:10.610]  rows back who's browsing Instagram. Another case that we were interested in for airplanes is
[31:10.610 --> 31:14.510]  something called a femtocell. There have been a couple of talks at DEFCON about it, I think.
[31:14.510 --> 31:19.170]  And it's essentially a miniature cell tower that they put in airplanes that allows customers to
[31:19.170 --> 31:23.970]  use their cell phones as if they were on the ground. And we saw that the front end of these
[31:23.970 --> 31:29.970]  is fairly secure. It uses GSM or LTE or whatever, which has some security guarantees over the air.
[31:29.970 --> 31:36.370]  But the back end was being routed unencrypted in these kind of SCTP wrappers over the satellite
[31:36.370 --> 31:41.370]  signal. And so we're able to see like the contents of people's cellular communications.
[31:41.370 --> 31:45.470]  What's particularly scary about this is that we don't know if these customers were aware
[31:45.470 --> 31:49.090]  of what they were doing. If you forgot to put your phone into airplane mode,
[31:49.090 --> 31:53.190]  it's very possible a text message that you received during your flight will show up in
[31:53.190 --> 31:56.790]  our packet captures. You're not even aware you're connected to a satellite network.
[31:57.190 --> 32:02.130]  And to kind of bring home the severity, here's a good example. There's this person who was on
[32:02.290 --> 32:05.810]  a flight and in the middle of their flight, they got their negative coronavirus test result.
[32:05.930 --> 32:09.690]  Now that's a huge relief for anyone who's sitting next to him on the airplane, right?
[32:09.690 --> 32:14.330]  But for the rest of us who care about health data privacy, it's a huge information breach that
[32:14.330 --> 32:19.050]  this is being sent in clear text across a continent. We saw all kinds of wild text messages.
[32:19.050 --> 32:23.630]  I remember listening to some guy who spoke Croatian in his text messages talking about
[32:23.810 --> 32:28.350]  a wild dream he had where his friend's mom showed up in a burning house or something.
[32:28.350 --> 32:33.090]  Just real people's personal communications are being sent in clear text. And it's not
[32:33.090 --> 32:38.730]  just personal communications. If you've ever used SMS as a second factor for account login,
[32:38.730 --> 32:42.390]  it's very clear how this could be deployed in an account hijacking attack.
[32:44.050 --> 32:49.010]  So fundamentally, everything we've done is passive. We haven't gotten any equipment to send signals
[32:49.010 --> 32:52.970]  in these networks. We don't have a license to do that. But is it possible that there are other
[32:52.970 --> 32:58.350]  sort of semi-active or fully active attacks we could deploy against these networks? One scenario
[32:58.350 --> 33:03.430]  I saw, which is based off of some malware that actually has been used in practice by a Russian
[33:03.430 --> 33:10.170]  group, would be to use satellites for untraceable data exfiltration. And there are only two
[33:10.170 --> 33:14.630]  requirements for this to play out. First, you have to compromise a device that you want to steal data
[33:14.630 --> 33:19.630]  from. And it needs to be connected to a network that has a route to a satellite IP address.
[33:19.770 --> 33:23.210]  Generally, the internet is sufficient because there are a lot of satellite devices that have
[33:23.210 --> 33:27.990]  internet routable IP addresses, but it could also be a device inside someone's LAN environment.
[33:28.870 --> 33:32.990]  Additionally, as an attacker, you need to be able to be inside that satellite signals
[33:32.990 --> 33:36.910]  forward link footprint. You need to be able to eavesdrop on the traffic. And that's it.
[33:36.910 --> 33:41.250]  Let's see how this plays out. So an attacker who's compromised the device has a problem.
[33:41.250 --> 33:45.630]  They want to send the sensitive data they've stolen to their server somewhere on the internet.
[33:45.630 --> 33:50.890]  The problem is that if they decide to just route this along the internet, just send a post request
[33:50.890 --> 33:56.650]  with whatever file they have to a web server they run, then law enforcement can very easily trace
[33:56.650 --> 34:01.390]  that post request and identify where the attacker's command and control server or data exfiltration
[34:01.390 --> 34:07.930]  database is. But if the attacker uses a satellite hop as an intermediary, they can really cause some
[34:07.930 --> 34:13.270]  trouble for law enforcement. Because you see, the compromised computer with the malware can send a
[34:13.270 --> 34:18.270]  signal to a satellite customer that will be routed over the satellite feed. And this customer doesn't
[34:18.270 --> 34:22.350]  need to be involved at all. It can just be a random ship in the ocean that happens to have an
[34:22.350 --> 34:26.670]  IP address. It doesn't even need a service running at that port. It could be a closed port or broken
[34:26.670 --> 34:30.990]  connection. And what will happen is the satellite will beam that signal down across its footprint
[34:30.990 --> 34:37.030]  area. And if the pilot, if a law enforcement officer tries to investigate this, they'll see it
[34:37.030 --> 34:43.830]  reach this like broken surface on a maritime ship and have no idea where it's gone. Meanwhile, behind
[34:43.830 --> 34:49.690]  the scenes, the attacker can be using a satellite dish to eavesdrop on that connection and leak
[34:49.690 --> 34:54.630]  information in clear text. Even if the satellite network had some degree of encryption, which there
[34:54.630 --> 34:59.690]  are some network out networks out there that do, the attacker might still be able to use even just
[34:59.690 --> 35:05.310]  the size of packets or the content of packets or the existence of packets as a signal that's
[35:05.310 --> 35:10.150]  virtually untraceable because they're somewhere in this massive continent-sized footprint and
[35:10.150 --> 35:15.770]  that's all law enforcement could possibly know. Another attack that we tried to pull off is
[35:15.770 --> 35:20.450]  something called TCP session hijacking, which is a very classic kind of networking attack.
[35:20.470 --> 35:24.810]  Essentially, TCP has this three-way handshake to set up connections where you have to know these
[35:24.810 --> 35:29.170]  randomly selected sequence numbers to prove you are who you say you are. And what we found is that
[35:29.170 --> 35:33.650]  in certain satellite environments, you could actually impersonate one of these endpoints very
[35:33.650 --> 35:39.510]  reliably due to the physical characteristics of orbit and hijack arbitrary TCP session numbers.
[35:39.570 --> 35:43.990]  We did this against our own connection to one device in one specific satellite network, but we
[35:43.990 --> 35:47.230]  didn't test it at a very broad scale because we didn't want to mess with anything important.
[35:47.570 --> 35:51.210]  Let me give you a show of how this kind of works from a physical perspective.
[35:51.330 --> 35:56.530]  Let's take a look. So just like before, we have someone in Ireland, only this time they're a
[35:56.530 --> 36:00.330]  maritime office that wants to visit a website that's hosted on the cargo vessel with status
[36:00.330 --> 36:06.930]  information. So what they'll do is they'll send a TCP SYN number as a start of a TCP three-way
[36:06.930 --> 36:11.350]  handshake. And this has a sequence number that you have to know to prove that you received the start
[36:11.350 --> 36:15.030]  of the handshake and that you're part of this conversation. This is like a very fundamental
[36:15.030 --> 36:20.270]  protection against spoofing attacks. However, our attacker can easily get the sequence number over
[36:20.270 --> 36:24.750]  the unencrypted satellite link. And at the next step, our attacker, remember how I said they were
[36:24.750 --> 36:31.190]  in Ghana? So Accra happens to have some of the fastest terrestrial internet in Africa and a
[36:31.190 --> 36:35.330]  direct backbone link to the UK, although that doesn't necessarily matter. But because the speed
[36:35.330 --> 36:41.250]  of light is only so fast, the attacker 100% of the time can beat the legitimate acknowledgement
[36:41.250 --> 36:46.350]  message from that handshake to our maritime office in Ireland. And at this point, the maritime office
[36:46.350 --> 36:50.410]  will start a conversation thinking they're talking to the vessel when they're actually
[36:50.410 --> 36:55.490]  sending information to our attacker. Our attacker can continue to eavesdrop over the satellite link
[36:55.490 --> 37:00.030]  and that message with their spoofed acknowledgement will reach the ship at sea, who will simply
[37:00.030 --> 37:03.530]  ignore it because it has incorrect sequence numbers. But our attacker at this point has
[37:03.530 --> 37:08.350]  free reign to send whatever information they want to the maritime office and impersonate the ship
[37:08.350 --> 37:12.050]  in a way that's virtually undetectable if you're not employing some sort of certificate signing
[37:12.050 --> 37:19.170]  scheme. So this is like a very simple example that shows that even though we can't transmit
[37:19.170 --> 37:23.030]  directly in the satellite network, we're fundamentally part of a broader network, which
[37:23.030 --> 37:28.310]  is the internet. And in that environment, active attacks are definitely possible. So obviously, this
[37:28.310 --> 37:33.010]  research has some ethical implications. It's real world networks and real people. So we're very
[37:33.010 --> 37:36.990]  careful to adhere to the laws and go above and beyond that. You might be a little disappointed
[37:36.990 --> 37:41.450]  today that I haven't named and shamed any companies. That's a conscious choice, because I don't want
[37:41.450 --> 37:45.670]  this to be about X airline is leaking your data. I want the focus to be on the fact that this is a
[37:45.670 --> 37:50.930]  systemic issue that affects a lot, thousands, tens of thousands of satellite customers around the world.
[37:51.690 --> 37:55.470]  We've, of course, engaged in responsible disclosure. Many of the satellite companies have known about
[37:55.470 --> 38:00.050]  this as early as 2019, as well as some of their customers who have leaked particularly interesting
[38:00.050 --> 38:04.930]  data or particularly large. Most people were receptive to this. We talked to a lot of CISOs
[38:04.930 --> 38:08.270]  who have started changing around their networks. We don't know exactly what they're doing, but at
[38:08.270 --> 38:12.290]  least they're aware of the risks. And we only had one company threatened to sue us, which is really
[38:12.290 --> 38:17.770]  good for this kind of systemic cybersecurity research. We got a huge boost to responsible
[38:17.770 --> 38:22.190]  disclosure, courtesy of the Federal Bureau of Investigation, who releases threat intelligence
[38:22.190 --> 38:28.050]  notification to the maritime industry. And what's really interesting about this notification is that
[38:28.050 --> 38:34.930]  it showed up online from the FBI almost a month before our academic paper was publicly available.
[38:34.930 --> 38:39.450]  So the only people that accessed this PDF file were people who were responsibly disclosed to you
[38:39.450 --> 38:45.430]  with the request that they keep it private and our academic peer reviewers. Yet somehow the FBI
[38:45.430 --> 38:51.550]  was able to cite specific information from a chart inside that paper. Now, as a researcher, this is,
[38:51.550 --> 38:55.390]  you know, a little bit unsettling. How did the FBI get my paper before I gave it to anyone?
[38:55.450 --> 38:58.450]  But if you're ever wondering that you should join one of these like threat intelligence
[38:58.450 --> 39:03.450]  schemes, it's like clear that the FBI does a good job at getting a scoop ahead of like
[39:03.450 --> 39:07.170]  the industry or even the researchers themselves thinking it's out there.
[39:07.810 --> 39:12.030]  So how do we protect against these attacks going forward? How do we defend these networks?
[39:12.170 --> 39:16.130]  Well, I think we need to understand why these kinds of attacks can happen. And it's easy to say
[39:16.130 --> 39:20.390]  it's because satellite operators are ignorant, but the reality is more complicated. Remember when I
[39:20.390 --> 39:24.970]  said the speed of light is only so fast? That means that sending a signal to space is slow,
[39:24.970 --> 39:29.890]  which makes all of those TCP connections you get when you visit a website add up to make your
[39:29.890 --> 39:35.170]  internet seem really slow. So what ISPs have done is they started splitting these handshakes as a
[39:35.170 --> 39:39.510]  man-in-the-middle attacker, basically, who benevolently accelerates your connection via
[39:39.510 --> 39:43.630]  what we call a performance-enhancing proxy. The problem is that if a customer uses like
[39:43.630 --> 39:47.770]  end-to-end encryption over a VPN, these performance-enhancing proxies can't find
[39:47.770 --> 39:54.650]  those TCP handshakes, and so they can't accelerate the connection. So in the short term, you might
[39:54.650 --> 39:58.810]  have to accept that as reality and just say, you know what, passport numbers are sensitive enough
[39:58.810 --> 40:03.190]  that we should send them encrypted or not send them at all. And in many cases, if you're using
[40:03.410 --> 40:08.890]  a TCP layer encryption protocol or a UDP encryption protocol, it doesn't affect performance at all.
[40:08.890 --> 40:12.790]  You should never be using POP for your emails, although we found thousands and thousands of
[40:12.790 --> 40:18.330]  people still do. You should be using an encrypted email client. And since ISPs are already screwing
[40:18.330 --> 40:22.950]  around with TCP sequence numbers and TCP sessions, if they just change those sequence numbers over
[40:22.950 --> 40:27.470]  the air from what they are on the ground, they can prevent TCP hijacking attacks. A lot of ISPs
[40:27.470 --> 40:32.090]  seem to do this already, although I think it's largely accidental. In the longer term, though,
[40:32.090 --> 40:36.810]  we're trying to work on a solution that makes it easier for individual customers to be sure their
[40:36.810 --> 40:41.030]  data is always encrypted, regardless of what protocol mistakes they might make. We're building
[40:41.210 --> 40:46.990]  a tool called QPEP, which uses the QUIC protocol, which is a TCP replacement that is encrypted by
[40:47.350 --> 40:51.530]  default. And it's kind of a combination between like a tunneling VPN and a performance enhancing
[40:51.530 --> 40:58.310]  proxy. If you want to take a look at QPEP, there is a public GitHub repository for it. This isn't
[40:58.510 --> 41:02.370]  a commercial product. The goal is to build a tool for people to start playing around with
[41:02.370 --> 41:07.050]  securing these networks. It's designed to be much more accessible than existing PEPs, which tend to
[41:07.050 --> 41:12.010]  be written in these obtuse C libraries for networking. It's written in Python as a test bed
[41:12.010 --> 41:16.090]  so you can simulate it without a satellite equipment at all. And most of the networking
[41:16.090 --> 41:21.750]  layer is written in Go for performance reasons. And the end goal is to help individuals protect
[41:21.750 --> 41:26.110]  their traffic instead of trying to berate ISPs into encrypting data, which we know doesn't work
[41:26.110 --> 41:32.990]  because we've been doing it since 2005. So this kind of shows the difference between those two
[41:32.990 --> 41:38.190]  options versus using an encrypted proxy like the one that we're building and using a very good
[41:38.190 --> 41:42.230]  open source VPN, but one that doesn't take into account the unique aspects of satellite
[41:42.230 --> 41:46.350]  communications. And you can see the difference in the amount of time it takes to load just a
[41:46.350 --> 41:51.570]  very typical web page as an indicator of why customers aren't encrypting their data. It's
[41:51.570 --> 41:55.670]  not that they don't know privacy is at risk. Many of the people responsibly disclosed to were like
[41:55.670 --> 42:01.430]  this isn't a security vulnerability because everyone knows about it, which has its own problems. But I
[42:01.430 --> 42:06.530]  think fundamentally when you give someone a choice between performance and privacy, it's very likely
[42:06.530 --> 42:11.490]  that they will choose performance, especially in an environment like satellite where you already have
[42:11.490 --> 42:16.830]  kind of sluggish connections. And so finding technological solutions that enable people to
[42:16.830 --> 42:21.790]  have as good of a performance as they've come to expect while adding in privacy basically invisible
[42:21.790 --> 42:27.350]  in the background is I think the best way that we can bolster privacy and security in these
[42:27.350 --> 42:34.110]  networks for real satellite customers. So to sum things up, today I've kind of presented the case
[42:34.110 --> 42:38.710]  that satellite broadband as it's used in the status quo is vulnerable to long-range eavesdropping
[42:38.710 --> 42:43.670]  attacks. Someone in a different country or on a different continent from you can be listening to
[42:43.670 --> 42:48.750]  your internet communications and yet many people act like this isn't the case. Whether it's a
[42:48.750 --> 42:53.850]  massive Fortune 500 company or a random person in a coffee shop somewhere, people are leaking
[42:53.850 --> 42:58.170]  deeply sensitive traffic over satellite feeds as if they don't know that an eavesdropper could be
[42:58.170 --> 43:03.250]  listening. We think this can be changed. We think the underlying reason that this is still a problem
[43:03.250 --> 43:08.670]  is that performant encryption is something that ISPs have to build into their satellite networks
[43:08.670 --> 43:12.650]  instead of something that individuals can just run for themselves when they connect to a satellite
[43:12.650 --> 43:17.090]  terminal. And we think that we can balance out that trade-off and bring security to customers
[43:17.090 --> 43:21.910]  regardless of how they interface with a satellite connection. So if I wanted to give a broader
[43:21.910 --> 43:27.450]  lesson, kind of a major takeaway from this talk that has almost nothing to do with satellites,
[43:27.450 --> 43:32.990]  it would be very simple. And that is that the next hop is unknown. When you connect to the internet,
[43:32.990 --> 43:37.210]  there's a whole web of different nodes and connections that's constantly changing that's
[43:37.210 --> 43:43.630]  routing your traffic. And any one of those nodes could be a satellite link or a wireless tower or
[43:44.130 --> 43:50.070]  a wiretapped ethernet cable. And so if we want to be sure that no one is listening to our traffic
[43:50.070 --> 43:54.090]  wherever it might go next, right? Because we could connect to a Wi-Fi hotspot and it could have
[43:54.090 --> 43:59.170]  the best encryption in the world. But if the next hop is a satellite link, that does us no good.
[43:59.330 --> 44:03.950]  So having the ability to encrypt your own traffic, having the right to encrypt your own traffic,
[44:03.950 --> 44:07.970]  and having the knowledge to make that encryption as secure and robust as possible
[44:07.970 --> 44:12.990]  is, I think, critical to preventing this whole class of attack regardless of the domain we
[44:12.990 --> 44:18.630]  consider it in. Thank you so much for listening to my presentation. I'm happy to answer any email
[44:18.630 --> 44:23.990]  questions via email or in a breakout session after this. And I hope you enjoyed the talk.
